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Applicant hereby appeals from the Final Rejection dated September 4, 2002, finally 
rejecting claims 1-17, 19-23 and 25-38. 

1. REAL PARTY IN INTEREST 
The real party in interest is Intel Corporation, the assignee of the present application by 
virtue of the assignment recorded at Reel/Frame 9408/0696. 



II. 



RELATED APPEALS AND INTERFERENCES 



There are no related appeals or interferences. 
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III. STATUS OF THE CLAIMS 
The application was originally filed with claims 1-30. During prosecution, claims 18 and 
24 were cancelled and claims 31-38 were added. Claims 1-17, 19-23 and 25-38 have been 
finally rejected and are the subject of this appeal. 

IV. STATUS OF AMENDMENTS 
In response to the Final Office Action, an amendment to claim 1 was submitted to clarify 
that the "at least one characteristic" on line 6 of claim 1 referred to "at least one predefined 
transmission characteristic." A communication fi*om the Examiner has not been received, 
indicating whether or not this amendment has been entered. It is assumed for purposes of this 
appeal that this amendment has been entered. Accordingly it is assumed that there are no 
unentered amendments. 

V. SUMMARY OF THE INVENTION 
Referring to Fig. 1, an example transmission system 8 (which may be an interactive 
broadcast system, for example) is illustrated that includes a broadcast headend system 10, one or 
more transports 20, and one or more platforms 30 to receive the broadcast signals. At the 
broadcast headend system 10, which includes a computer system along with other broadcast- 
related components (which may be located at a TV studio, for example), digital data are provided 
to a system containing interactive broadcasting application programs 12, which assemble the 
received digital data into packages and schedule them for insertion into a broadcast signal. The 
assembled data from the interactive broadcasting application programs 12 are routed to a data 
inserter unit 15 including a bridge unit 14, which also receives broadcast program video and 
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audio data (TV data). The bridge unit 14 multiplexes the digital data and the TV data and 
provides the combined data to an uplink block 16. In some embodiments, the system containing 
the interactive broadcasting application programs 12 and the data inserter unit 15 may be 
separate systems, while in other embodiments the units may be implemented as one integrated 
system. Specification, pp. 2-3. 

The uplink block 16 in turn transmits (by broadcasting or multicasting, for example) the 
combined digital and TV data over one or more transport media or communications channels 20, 
which may be the broadcast airwaves, a cable medium, a satellite medium, a computer network 
(such as local area networks, wide area networks, or the Internet), or a digital TV medium, to one 
or more platforms 30. An example platform 30 may include a TV-enabled computer 32 that is 
configured to receive the combined digital and PC broadcast data over the transport medium 20. 
The computer 32 may also include a modem 34 that may be connected to an Internet Web server 
22. Specification, p. 3. 

According to embodiments of the invention, the bridge unit 14 is able to automatically 
adjust for the different characteristics of different transport media 20, including data flow rates 
and other characteristics as described below. Further, each particular transport medium may 
have transport characteristics that vary over time, for which the bridge unit 14 may also make 
adjustments. The bridge unit 14 may be implemented entirely in software that runs in the 
computer system in the broadcast headend system 10, or alternatively, the bridge unit 14 may be 
a combination of hardware and sofl^^are. Specification, p. 3. 



3 



i 



m % 



In some embodiments, the bridge unit 14 and uplink block 16 include several components 
as shown in Fig. 2. The bridge unit 14 includes a broadcast encoder 100 (implemented in one 
embodiment as a software module) that interleaves digital data received from the application 
programs 12 with television programming data. The broadcast encoder 100 is able to work with 
a number of different types of transport media 20. To provide for such flexibility, one or more 
different transmitters 102 that are configured for corresponding transport media are also included 
in the bridge unit 14. In one embodiment, each transmitter 102 is essentially a transport 
abstraction implemented as a software module that acts as the interface between application 
programs (including the broadcast encoder 100), and the connected transport media 20. 
Specification, p. 3. 

In one embodiment, the broadcast encoder 100 and one or more of the transmitters 102 
exchange information on a "continuous" (or continued) basis so that the broadcast encoder 100 
may efficiently and reliably manage communications for different transport media and as 
transmitter characteristics change. The exchange of information may be performed by the 
broadcast encoder 100 periodically polling each transmitter 102 or by a transmitter 102 
requesting an update, for example. The exchange of information is continuous in the sense that 
the broadcast encoder 100 and transmitters 102 continue to exchange information after startup of 
the broadcast encoder 100 or one of the transmitters 102. In an alternative embodiment, multiple 
broadcast encoders may be specified for use with multiple corresponding transmitters. 
Specification, p. 4. 
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Advantages of embodiments of the invention may include the ability to automatically 
control data flov/ that is transparent to application programs in the broadcast headend system 10. 
In addition, embodiments of the invention may allow for transport independence at the broadcast 
headend in interactive broadcast systems. Specification, p. 4. 

The broadcast encoder 100 mixes the digital data and the TV programming data 
according to the type of transport medium 20 used. For example, if the transport medium uses 
an analog broadcast signal (transmitted over analog airwave or cable media, for example), the 
digital data is inserted into the vertical blanking interval (VBI) portion of the broadcast signal. 
The VBI portion of the broadcast signal may also be used to transmit, among other things, closed 
captioning data. Conventionally, in an analog broadcast signal, a predetermined number (e.g., 
10) of VBI lines are available, with each line having a predetermined data transmission capacity. 
A portion of the available VBI lines is typically used to carry the digital data. Specification, p. 4. 

Other transport media, such as satellite transmissions or digital TV transmissions, may 
have much higher data transmission rates. Specification, p. 4. 

Data from the bridge unit 14 is transmitted to the uplink unit 16, which typically may 
include a hardware unit (or sometimes a software stack) that ships the data along with other 
contents over a specified transport medium 20, which may be any network that supports 
broadcast or multicast transmissions. Specification, p. 4. 

Characteristics of a transport medium 20 are communicated by a corresponding 
transmitter 102 to the broadcast encoder 100 through negotiations between the broadcast encoder 
and the transmitters. Each transmitter 102 may be configured as a separate module, such a 
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Component Object Model (COM) object. The COM specification is described in "The 
Component Object Model Specification," Draft Version 0.9, Microsoft Corporation and Digital 
Equipment Corporation (October 1995). Specification, pp. 4-5. 

The behavior of the broadcast encoder 100 is modified based on the capabilities that the 
one or more transmitters 102 advertise. The broadcast encoder 100 and each transmitter 102 are 
loosely coupled, with the communications between a transmitter and the broadcast encoder in 
one embodiment being accomplished through an application specific interface (API). During 
negotiations between the broadcast encoder 100 and each transmitter 102 through the API 
interface, the broadcast encoder 100 obtains details of the characteristics of each transmitter 102 
to allow the broadcast encoder 100 to efficiently manage data communications over the transport 
media 20. In the API interface, several methods are defined through which the broadcast 
encoder and transmitters exchange information. Specification, p. 5. 

To increase efficiency of data transfer between the broadcast encoder and the transmitter, 
each transmitter 102 according to an embodiment is configured as a COM object to the broadcast 
encoder that has two interfaces: ITransmitter, which is the transmitter's primary interface for 
data communication and control; and the IPropertyPage interface for configuration management. 
Any application (including the broadcast encoder 100) that uses the transmitters 102 in the 
described embodiment first obtains the ITransmitter interface to set up communications with 
each transmitter 102. Specification, p. 5. 

In alternative embodiments, negotiations between the broadcast encoder and each 
transmitter may be accomplished with other interfaces, including use of OLE events defined 
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under the Object Linking and Embedding (OLE) standard, described in David Chappell, 
"Understanding ActiveX and OLE: A Guide for Developers & Managers," published in 1996. 
Specification, p. 5. 

In the described embodiment, the transmitter 102 may accept two general types of data: 
raw data streams or predefined datagrams. Raw data streams are transmitted by the broadcast 
encoder 100 or another application by calling a SendQ method, and datagrams are transmitted 
using a SendDatagramsQ method. When data is provided by the broadcast encoder 100 or some 
other application to the transmitter 102 using the SendQ method, the transmitter 102 does not 
know the type of data that is passed to it. When a transmitter 102 receives this kind of data, it 
does not interpret this data but instead passes the data on to another device or software module. 
Specification, pp. 5-6. 

The Send() method in one embodiment writes the data pointed to in the method to a 
target transmitter 102. When a Send() call returns, the broadcast encoder 100 along with the 
other applications may assume that the data bits have actually been written to the transmitter. 
The Send() method is a blocking call, and will return a value if one of the following conditions 
occur: the transmission was successful, a timeout occurred, an error occurred, or the caller has 
aborted the call. Specification, p. 6. 

The other type of data, predefined datagrams such as Internet Protocol (IP) or User 
Datagram Protocol (UDP) datagrams that are transmitted by calling the SendDatagrams() 
method, have known formats. The SendDatagrams() method is similar to the SendQ method. 
The IP protocol is described in "Intemet Protocol, DARPA Internet Program, Protocol 
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Specification " Request for Comment 791 (September 1981), and the UDP protocol is described 
in "User Datagrams Protocol," Request for Comment 768 (August 1980). Each datagram may 
include header information that may have the following types of information: version 
information; length of the header; type of datagram, including UDP, IP, and raw data; length of 
the data; flags; compression used; and other information. A datagram header may also be 
followed by broadcast encoder data that describe certain details of the broadcast encoder 100. 
The datagram also includes the actual data that is being transmitted. An example IP datagram is 
shown in Fig. 3, in which a block 60 contains the header information and broadcast encoder 
information, a block 64 contains the actual data, and a block 62 may optionally be used as a pad 
region. A transmitter 102 is able to reformat a datagram received from the broadcast encoder 
100 or other application program for transmission further downstream. Specification, p. 6. 

The behavior of the broadcast encoder 100 is dependent on information advertised by 
each transmitter 102 from negotiations the broadcast encoder 100 performs with one or more 
transmitters 102. Depending on how many transport media 20 is used in the system, more than 
one transmitter 102 may be active at the same time. According to an embodiment of the 
invention, several methods may be used to perform these negotiations, including 
GetConfigurationO, GetAdjustmentRate(), GetNumSendErrors(), and GetFreeBuff(), which are 
discussed further below. Specification, pp. 6-7. 

Referring to Fig. 4, the tasks performed by the broadcast encoder 100 of one embodiment 
during the negotiation process with the transmitter 102 are described. First, through the 
IPropertyPage API interface, the broadcast encoder 100 loads (at 202) the one or more 
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designated transmitters 102 into the broadcast headend system 10. Transmitters may be 
designated in a preselected database, such as the registry under the Windows operating system. 
In addition, the loaded transmitters 102 are initialized (at 204) by calling a method InitializeQ. 
Once an InitializeQ method is issued, each transmitter 102 responds by allocating memory (such 
as internal buffers) and initializing any variables and device settings. The Initialize() method 
may be a blocking call, with the call returning only if the system is really initialized. The 
broadcast encoder 100 checks (at 206) to determine if the loading and initialization is successful. 
If a failure is detected, then the broadcast encoder 100 designates itself as being in a Homeless 
state (at 208), in which the broadcast encoder 100 does not accept or send any data. 
Specification, p. 7. 

But if the loading and initialization were successful (as determined at 206), then the 
broadcast encoder 100 requests (at 210) the configuration information from the one or more 
transmitters 102 using the GetConfiguration() method. When a transmitter receives the 
GetConfigurationO call, the transmitter advertises its capabilities. Some of the outputs are 
already known to the broadcast encoder 100 and some are specific to the class of transmitter 
involved. For example, a transmitter associated with a VBI transport will have a field indicating 
the number of VBI lines used. The types of information that a transmitter can send include the 
following: the version, length of the header, name of the transmitter, some description of the 
transmitter, the transfer rate, the maximum transmission unit, the buffer size, if any, the timeout 
and seconds per datagram (if any), the data gram type (UDP, IP, or raw data), flags, padding 
size, and other information. The configuration information received from each transmitter 102 is 
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stored in memory by the broadcast encoder 100 at predefined memory locations. The stored 
transmitter configuration information is used at a later time to modify the broadcast encoder's 
behavior. Specification, p. 7. 

Next, the broadcast encoder 100 may send (at 212) device specific information 
(information describing certain details of the broadcast encoder 100) to each of the transmitter 
102. In the illustrated embodiment, the method used to communicate this information is a 
RegisterStreamO method. The broadcast encoder 100 stores all the stream-related information in 
a data structure (referred to as OPENSTREAM) and allocates a handle (address information 
indicating where the OPENSTREAM structure is stored) that is passed to the transmitter 102 in 
the RegisterStreamO method. This handle may be passed by the broadcast encoder 102 in 
subsequent datagrams (in block 60 of the example datagram of Fig. 3). Specification, p. 8. 

Next, the broadcast encoder uses (at 214) the configuration information advertised by 
each transmitter 102 in response to the GetConfiguration() method to modify its behavior. In the 
illustrated embodiment, the configuration information is stored in a data structure, referred to as 
the CONFIG data structure. Transmitters associated with different transport media have 
different characteristics. Some characteristics may include the maximum transfer rate that a 
transport medium can handle, the maximum size of each data packet (also refer to as the 
maximum transmission unit or MTU), whether compression is used, whether internal buffers are 
used in the transmitter, the type of data management (if any) performed by each transmitter, 
whether framing of data is performed, and whether fragmentation of the data is performed. 
Specification, p. 8. 
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Another characteristic of a transmitter is whether it understands the concept of priorities. 
Thus, if the transmitter is able to assign priorities to data it receives, then the broadcast encoder 
100 does not perform priority assignment, leaving the task to the transmitter 102. If the 
transmitter 102 is unable to prioritize the received data stream, then the broadcast encoder 100 
multiplexes the data stream based on the requested priority from the application programs 12. 
Specification, p. 8. 

Yet a further transmitter characteristic is bandwidth management, in which the 
transmitter 102 may advertise that it is able to perform bandwidth management. Similarly, the 
broadcast encoder 100 may also optionally allow the transmitter 102 to perform data 
compression if the transmitter 102 is able to do so. Other characteristics that may be negotiated 
between the broadcast encoder and the transmitters include the basic data types that a transmitter 
requires. In one embodiment, the data types include raw data streams, Internet Protocol (IP) 
data, user datagram protocol (UDP) data, or other types of data. Raw data streams may be used 
in network interfaces not requiring an IP or UDP header. In addition, a transmitter 102 may ask 
the broadcast encoder 100 to repackage data before it is transmitted to the transmitter. 
Specification, pp. 8-9. 

Some of the characteristics of the transmitters are further discussed below. The 
maximum transmission unit (MTU) refers to the maximum size of a single IP or UDP datagram. 
If an MTU is advertised, the broadcaster encoder 100 sets the size of each datagram to be less 
than or equal to the advertised MTU. If a software layer (such as the broadcaster encoder 100) 
sends data that is more than the specified MTU size, then the IP layer (such as the transmitter 
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102) may fragment the data into MTU-sized datagrams before further transmission. In some 
embodiments, a transmitter 102 does not need to advertise the MTU of its transport medium. 
Instead a transmitter 102 may advertise its MTU as having the value zero, in which case the 
transmitter 102 would perform its own internal buffering, fragmentation, and data management. 
Specification, p. 9. 

In addition to using the configuration information advertised by the transmitters, other 
methods used by the broadcast encoder 100 to determine transmitter characteristics include the 
GetAdjustedTransferRateO method, which calculates the actual transfer rate adjusted for delays 
and overhead in the transmitter 102. The GetAdjustedTransferRateO method obtains the 
adjusted rate of transfer in bits per second that accounts for the network traffic, hardware and 
software overhead and other delays. A transmitter may have some intelligent mechanism to 
study the flow and return and appropriate value, and this value may vary from time to time 
depending on such conditions as the network traffic. The broadcast encoder will use this 
adjusted transfer rate to arrive at a transfer rate to perform the transfer of data to the transmitter. 
Specification, p. 9. 

The adjusted transfer rate effectively is the data transfer rate that the transmitter 102 is 
able to handle. To effectively manage the data flow, the broadcast encoder 100 also needs to 
account for the incoming data flow rate. The broadcast encoder 100 may receive input data from 
several sources, each potentially at different rates. Further, the broadcast encoder may include 
one or more buffers to store incoming data. Some transmitters 102 may also have this capability. 
Transmitters that include an internal cache (or buffer) that is able to hold data are referred to as 
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"none-blocking transmitters." The second type of transmitter does not cache data at all, in which 
case all SendQ and SendDatagramsQ calls are blocked until data actually is sent by the 
transmitter. Such tt-ansmitters are referred to as "blocking transmitters." The broadcast encoder 
100 may determine if a transmitter 102 includes data buffers by calling the method 
GetFreeBuffQ. If a transmitter 102 includes a buffer, then it may be able to handle a faster data 
flow from the broadcast encoder 100 to the transmitter 102. In addition, the broadcast encoder 
100 determines how fast retums are received from SendQ or SendDatagramQ calls. Using the 
adjusted transfer rate, incoming data rate or rates, the existence of buffers in the transmitters 102, 
and the speed of rettams in response to the SendQ or SendDatagramsQ methods, all negotiated on 
a continuous basis between the broadcast encoder 100 and each of the transmitters 102, the 
broadcast encoder 100 is able to perform effective data flow control. Specification, pp. 9-10. 

Referring to Fig. 5, an example computer system 200 used in the broadcast headend 
system 10 may include a microprocessor 210 that is capable of running the broadcast encoder 
100 and transmitters 102 according to embodiments of the invention. A system memory 218, the 
microprocessor 210, and a bridge/system controller circuitry 214 are all coupled to a host bus 
212. The bridge circuitry 214 provides an interface from the host bus 212 to a down stream bus 
229 that is coupled to an I/O controller 220 and a network interface card 222, as examples. The 
I/O controller 220 may also be coupled to serial and parallel ports 232. The computer 200 may 
also have, as examples, a CD or DVD drive 230, a floppy disk drive 224, and/or a hard disk 
drive 226. Specification, p. 10. 
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According to some embodiments, the broadcast encoder 100 and transmitters 102 may be 
stored on a suitable mass storage medium such as the CD or DVD drive 230, the floppy disk 
drive 224, or the hard disk drive 226. During execution, the broadcast encoder 100 and 
transmitters 102 or portions of the software modules may loaded into the system memory 218 for 
execution by the microprocessor 210. Data generated by the transmitters 102 may be transmitted 
over the network, serial or parallel ports, or other interfaces (not shown) to the uplink unit 16. 
Specification, p. 10. 

Thus, by continuously monitoring transmitter characteristics, the broadcast encoder can 
efficiently and accurately manage the transmission of broadcast signals containing both digital 
data and TV data over one or more transport media. Because the broadcast encoder monitors the 
transmitters on a continuous basis, changes in characteristics of a transmitter and corresponding 
transport medium can be ascertained by the broadcast encoder for adjustments. Specification, 
pp. 10-11. 

Other embodiments are also included in the following claims. For example, even though 
specific units have been identified in the interactive broadcast system, other types of units may 
be used. In addition, the order of the tasks illustrated for the broadcast encoder may be modified 
and still achieve desirable results. Specification, p. 1 1. 
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VL ISSUES 

A. Can claims 1-13, 31 and 32 be rendered obvious when the Examiner has failed to 
establish a prima facie case of obviousness for independent claim 1? 

B. Can claims 14-17, 19, 20, 33 and 34 be rendered obvious when the Examiner has 
failed to establish a prima facie case of obviousness for independent claim 14? 

C. Can claims 21-23, 25, 26, 35 and 36 be rendered obvious when the Examiner has 
failed to establish a prima facie case of obviousness for independent claim 21? 

D. Can claims 27-30, 37 and 38 be rendered obvious when the Examiner has failed to 
establish a prima facie case of obviousness for independent claim 27? 

VII. GROUPING OF THE CLAIMS 
Claims 1-13, 31 and 32 can be grouped together; claims 14-17, 19, 20, 33 and 34 can be 
grouped together; claims 21-23, 25, 26, 35 and 36 can be grouped together; and claims 27-30, 37 
and 38 can be grouped together. With this grouping, all claims of a particular group stand or fall 
together. Furthermore, all claims of a particular group stand alone with respect to the claims of 
another group. In this manner, all claims of a particular group do not stand or fall together with 
any of the claims of another one of the groups. 

VIIL ARGUMENT 
All claims should be allowed over the cited references for the reasons set forth below. 

A. Can claims 1-13, 31 and 32 be rendered obvious when the Examiner has failed to 
establish a prima facie case of obviousness for independent claim 1? 

The transmission system of claim 1 includes a transmitter module that is coupled to a 
transport medium and to a data management model. The transmitter module contains 
configuration information that specifies at least one predefined transmission characteristic. The 
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data management model accesses the configuration infomiation to determine the predefined 
transmission characteristic(s) and modifies the data flow management based on the predefined 
transmission characteristic(s). 

The Examiner rejects independent claim 1 under 35 U.S.C. § 103(a) in view of U.S. 
Patent No. 6,044,396 (herein called '*Adams") and U.S. Patent No. 6,185,736 (herein called 
'*Ueno"). Adams generally teaches a system that includes a modulator 210 (see Fig. 2) that 
modulates a data to be transmitted to a cable. See, for example, Adams, 3:53-67. Adams 
presents no disclosure regarding configuration information for the modulator 210. 

Ueno is generally directed to communicating data over a netAvork. Ueno generally 
teaches a notification parameter file 19. This notification parameter file 19 indicates an amount 
of data to be transmitted by a video server 1 1 over a predefined window of time. See, for 
example, Ueno, 9:20-32. 

The Examiner fails to establish a prima facie case of obviousness for claim 1 for at least 
the reason that the Examiner fails to show the alleged suggestion or motivation to combine 
Adams and Ueno. This is improper, as the Examiner must show, with specific citations to the 
prior art, where the prior art discloses such a suggestion or motivation. Ex parte Gambogi, 62 
USPQ2d 1209, 1212 (Bd. Pat. App. & Int. 2001); /n reRijckaert, 28 USPQ2d 1955, 1957 (Fed. 
Cir. 1993); M.P.E.P. § 2143. Thus, for at least the reason that the Examiner fails to show any 
support for the alleged suggestion or motivation to combine Ueno and Adams, a prima facie case 
of obviousness has not been established for independent claim 1 . 
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Furthermore, the Examiner fails to show any support for the alleged suggestion or 
motivation to modify either reference to derive the claimed invention. Contrary to the 
Examiner's untenable conclusion, the modification of the alleged data management module (i.e., 
the circuits 1002, 708, 208, 206, 204 and 202, as set forth by the Examiner) of Adams so that the 
alleged data management module modifies a data flow predefined transmission characteristic(s) 
based on the notification parameter file 19 of Ueno. The alleged data management module of 
Adams is a transmitter circuit that transmits data to a network. See, for example, Figs. 1 and 2 of 
Adams. However, as noted above, the notification parameter file 19 of Ueno indicates an 
amount of data to be transmitted by a video server 1 1 to a network over a predefined window of 
time so that the network may allocate a bandwidth for data that is transmitted from the video 
server. See, for example, Ueno, 7:1 1-20. Modifying Ueno so that the notification parameter file 
19 is used to modify a data management flow of a transmitter circuit that transmits data to the 
network would improperly change the principle of operation of Ueno's system. M.PE.P. § 
2145.X.D. Therefore, one skilled in the art would not have been motivated to combine these two 
references or modify these references in the fashion contended by the Examiner. 

Claims 2-13, 31 and 32 are patentable for at least the reason that these claims depend 
fi*om an allowable claim. 

Thus, for at least these reasons, the § 103(a) rejections of claims 1-13, 31 and 32 are 
improper and should be reversed. 
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B. Can claims 14-17, 19, 20, 33 and 34 be rendered obvious when the Examiner has 
failed to establish a prima facie case of obviousness for independent claim 14? 

The transmission system of independent claim 14 includes a data management program 
that is capable of assembling data and a transmitter that is capable of receiving data from the data 
management program and transmitting the data to a transport medium. The data management 
program accesses configuration information that specifies a characteristic of the transmitter and 
modifies the management of data based on the configuration information. 

The Examiner rejects claim 14 under 35 U.S.C. § 103(a) in vievc^ of U.S. Patent No. 
6,078,919 (herein called "Ginzburg") and Ueno. Ueno is discussed above in connection v^ith the 
discussion of Issue A. Ginzburg generally teaches a method and apparatus for delivery of data 
over a network based on determination of network parameters. 

The Examiner fails to establish a prima facie case of obviousness for independent claim 
14 for at least the reason that the Examiner fails to provide any support for the alleged suggestion 
or motivation to combine Ginzburg and Ueno. In this manner, the Examiner merely concludes 
the existence of such a suggestion or motivation without citing to any specific language in any of 
the cited prior art references. Thus, the Examiner has failed to establish the existence of the 
alleged suggestion or motivation to combine Ginzburg and Ueno. Ex parte Gambogi, 62 
USPQ2d 1209, 1212 (Bd. Pat. App. & Int. 2001); In re Rijckaert, 28 USPQ2d 1955, 1957 (Fed. 
Cir. 1993); M.P.E.P. § 2143. Therefore, for at least the reason that the Examiner fails to show 
any support for the alleged suggestion or motivation to combine Ginzburg and Ueno, a prima 
facie case of obviousness for independent claim 14 has not been established. 
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Additionally, the Examiner provides no support for the alleged suggestion or motivation 
to modify either cited reference in the prescribed manner. To the contrary, the combination of 
Ginzburg and Ueno in the manner set forth by the Examiner would improperly change the 
principle of operation of Ueno. More specifically, the Examiner labels the server 17 of Ginzburg 
as the alleged transmitter of claim 14. However, claim 14 specifies that the transmitter is capable 
of receiving data fi-om the data management program and transmitting this data to a transport 
medium. Therefore, if it is assumed that the network 16 is the alleged transport medium, this 
means the server 17 must receive data fi'om some data management program within. Thus, it 
appears the Examiner is labeling the server software system 18 as the alleged data management 
program of claim 14. As noted above, Ueno teaches a notification parameter file 19 that 
indicates data to be transmitted from a particular transmitter. Modifying Ueno so that the 
notification parameter file 19 is used to modify a data management flow of a transmission 
device, such as the software server system 18, to transmit data to the network would improperly 
change the principle of operation of Ueno's system. M.PE.P. § 2145.X.D. 

Claims 15-17, 19, 20, 33 and 34 are patentable for at least the reason that these claims 
depend from an allowable claim. 

Thus, for at least the reasons set forth above, the § 103(a) rejections of claims 14-17, 19, 
20, 33 and 34 are improper and should be reversed. 

C. Can claims 21-23, 25, 26, 35 and 36 be rendered obvious when the Examiner has 
failed to establish a prima facie case of obviousness for independent claim 21? 

The computer-readable medium of claim 21 stores a program that is executable by a 
computer in a transmission system that includes a transmitter. The program includes instructions 
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causing the computer to receive stored information to identify at least one transmission 
characteristic of the transmitter and modify a data flow management based on the identified 
transmission characteristic(s). 

The Examiner rejects independent claim 21 under 35 U.S.C. § 103(a) as being 
unpatentable over the combination of Ginzburg and Ueno. However, the Examiner provides no 
support for the alleged suggestion or motivation for the modification of Ginzburg so that a 
program of Ginzburg causes a computer in a transmission system of Ginzburg to modify data 
based on an indication of a transmitted data rate. Without support for the alleged suggestion or 
motivation for this combination and/or modification, a prima facie case of obviousness has not 
been established for independent claim 2\, Ex parte Gambogi, 62 USPQ2d 1209, 1212 (Bd. Pat. 
App. & Int. 2001); In reRijckaert, 28 USPQ2d 1955, 1957 (Fed. Cir. 1993); M.P.E.P. § 2143. 
Additionally, modifying Ueno so that the notification parameter file 19 is used to modify a data 
management flow of a transmission device, such as the software server system 18, to transmit 
data to the network would improperly change the principle of operation of Ueno*s system. 
M.PE.P. § 2145,X.D. This contradicts an alleged suggestion or motivation to combine Ueno and 
Ginzburg in the manner set forth by the Examiner. 

Claims 22, 23, 25, 26, 35 and 36 are patentable for at least the reason that these claims 
depend from an allowable claim. 

Thus, for at least the reasons set forth above, the § 103(a) rejections of claims 21-23, 25, 
26, 35 and 36 are improper and should be reversed. 
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D. Can claims 27-30, 37 and 38 be rendered obvious when the Examiner has failed to 
establish a prima facie case of obviousness for independent claim 27? 

The method of claim 27 is for managing data flow over a transport medium in an 
interactive transmission system. The method includes accessing stored configuration 
information and identifying, based on the accessed configuration information, at least one 
transmission characteristic of a transmitter that is used to transmit data over a transport medium. 
The method includes modifying data flow management based on the identified transmission 
characteristic(s). 

The Examiner rejects independent claim 27 under 35 U.S.C. § 103(a) as being 
unpatentable over the combination of Ginzburg and Ueno. However, the Examiner fails to 
provide any support for the alleged suggestion or motivation for the combination of Ginzburg 
and Ueno. In this manner, the Examiner provides no support for the alleged suggestion or 
motivation to modify the data flow inside the client 14 of Ginzburg in view of a transmission rate 
that is transmitted by a video server 1 1 of Ueno. Thus, the Examiner has failed to show any 
support for the alleged suggestion or motivation. Ex parte Gambogi, 62 USPQ2d 1209, 1212 
(Bd. Pat. App. & Int. 2001); In reRijckaert, 28 USPQ2d 1955, 1957 (Fed. Cir. 1993); M.P.E.P. 
§2143. Modifying Ueno so that the notification parameter file 19 is used to modify a data 
management flow of a transmission device, such as the software server system 18, to transmit 
data to the network would improperly change the principle of operation of Ueno's system. 
M.PE.P. § 2145.X.D. 

Claims 27-30, 37 and 38 are patentable for at least the reason that these claims depend 
from an allowable claim. 
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Thus, for at least the reasons set forth above, the § 103(a) rejections of claims 27-30, 37 
and 38 are improper and should be reversed. 



IX. CONCLUSION 
The Assignee requests that each of the final rejections be reversed and that the claims 
subject to this appeal be allowed to issue. 

Respectfully submitted, 



Date: April 10, 2003 
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APPENDIX OF CLAIMS 

The claims on appeal are: 

1 . A transmission system, comprising: 

a data management module capable of managing data flow; and 

a transmitter module coupled to a transport medium and to the data management module, 
the transmitter module to contain configuration information specifying at least one predefined 
transmission characteristic, 

the data management module to access the configuration information to determine the at 
least one predefined transmission characteristic and to modify data flow management based on 
the at least one predefined transmission characteristic, 

2. The transmission system of claim 1, further comprising at least an additional 
transmitter module. 

3. The transmission system of claim 2, wherein each transmitter module is 
associated with a different transport medium. 

4. The transmission system of claim 1, wherein the transmission characteristic of the 
transmitter module varies over time. 

5. The transmission system of claim 1, further comprising an interface between the 
data management module and the transmitter module. 
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6. The transmission system of claim 5, wherein the interface includes an API 
interface. 

7. The transmission system of claim 1, wherein the transmission characteristic 
includes a data flow rate of the transmitter module. 

8. The transmission system of claim 7, wherein the data flow rate is adjusted to 
compensate for delays in the transmitter module. 

9. The transmission system of claim 1, the data management module to continue to 
receive the transmitter's transmission characteristic and to adjust the data flow management if 
the transmission characteristic changes. 

10. The transmission system of claim 1, the data management module to combine 
digital data with television data to transmit over the transport medium. 

11. The transmission system of claim 1, wherein the transport medium includes a 
medium selected from the group consisting of an airwave transmission, a cable transmission, a 
satellite transmission, a digital television transmission, and a computer network. 

12. The transmission system of claim 1, wherein the configuration information is 
retrieved by the data management module at startup of the transmitter module or data 
management module. 



13. The transmission system of claim 12, the data management module and 
transmitter module to continue to exchange configuration information after startup. 

14. A transmission system comprising: 

a data management program capable of assembling data; 

a transmitter capable of receiving data from the data management program and 
transmitting the data to a transport medium; and 

a communication interface between the data management program and the transmitter 
that enables the data management program and transmitter to negotiate the type of 
communication to be performed, 

the transmitter to contain configuration information specifying a characteristic of the 
transmitter, 

the data management program to access the configuration information of the transmitter 
and to modify management of data flow based on the configuration information. 

15. The transmission system of claim 14, wherein the assembled data includes digital 
data and television data. 

16. The transmission system of claim 14, further comprising at least another 
transmitter coupled to at least another transport medium. 

17. The transmission system of claim 16, wherein the transport media have different 
transmission characteristics. 
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19. The transmission system of claim 16, the data management program and 
transmitters to exchange information on a continuous basis. 

20. The transmission system of claim 17, wherein the transport media have different 
data flow rates. 

21. A computer-readable medium storing a program executable by a computer in a 
transmission system including a transmitter coupled to a transport medium, the program 
comprising instructions for causing the computer to: 

retrieve stored information to identify at least one transmission characteristic of the 
transmitter; and 

modify data flow management based on the identified at least one transmission 
characteristic. 

22. The computer-readable medium of claim 21, the program further comprising 
instructions causing the computer to identify a transmission characteristic of at least another 
transport medium over which data is to be transmitted by at least another transmitter. 

23. The computer-readable medium of claim 22, wherein the transport media have 
different transmission characteristics. 

25. The computer-readable medium of claim 21, wherein the transmission system 
further includes a data management module, the program further comprising instructions causing 
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the computer to cause the data management module and transmitter to exchange information 
relating to the transport medium's at least one transmission characteristic. 

26. The computer-readable medium of claim 25, wherein the data management 
module and transmitter exchange information on a continuous basis. 

27. A method of managing data flow over a transport medium in an interactive 
transmission system, comprising: 

accessing stored configuration information; 

identifying, based on the accessed configuration information, at least one transmission 
characteristic of a transmitter used to transmit data over the transport medium; and 

modifying data flow management based on the identified at least one transmission 
characteristic. 

28. The method of claim 27, further comprising identifying a transmission 
characteristic of at least another transmitter used to transmit data over a different transport 
medium. 

29. The method of claim 27, wherein the transmitters associated with the different 
transport media have different transmission characteristics. 

30. The method of claim 27, wherein the at least one transmission characteristic of the 
transmitter is identified on a continuous basis. 



31. The transmission system of claim 1, the configuration information to specify one 
or more of the following: 

maximum transfer rate, maximum size of each data packet, and usage of compression. 

32. The transmission system of claim 1, wherein the configuration information 
comprises at least one of information to indicate if the transmitter module is able to assign 
priorities to data, and information to indicate if the transmitter module is able to perform 
bandwidth management. 

33. The transmission system of claim 14, the configuration information to specify one 
or more of the following: 

maximum transfer rate, maximum size of each data packet, and usage of compression. 

34. The transmission system of claim 14, wherein the configuration information 
comprises at least one of information to indicate if the transmitter module is able to assign 
priorities to data, and information to indicate if the transmitter module is able to perform 
bandwidth management. 

35. The computer-readable medium of claim 21, wherein the information specifies 
one or more of the following: 

maximum transfer rate, maximum size of each data packet, and usage of compression. 
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36. The computer-readable medium of claim 21, wherein the information comprises 
at least one of information to indicate if the transmitter module is able to assign priorities to data, 
and information to indicate if the transmitter module is able to perform bandwidth management. 

37. The method of claim 27, the configuration information to specify one or more of 
the following: 

maximum transfer rate, maximum size of each data packet, and usage of compression. 

38. The method of claim 27, wherein the configuration information comprises at least 
one of information to indicate if the transmitter module is able to assign priorities to data, and 
information to indicate if the transmitter module is able to perform bandwidth management. 
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